fix(tool): chart only this repo — the workflow token can't read siblings - #156
Conversation
The first live run of the new workflow failed, and the fail-closed behaviour added in the previous commit is the reason we found out cleanly rather than silently shipping a worse chart. A workflow's built-in GITHUB_TOKEN is scoped to its own repository, so reading OpenStrap/protocol from a job running in OpenStrap/edge returns 403 "Resource not accessible by integration". The generator listed all three repos, so the run aborted: error: gh api repos/OpenStrap/protocol/stargazers... failed: 403 — aborting rather than publishing a partial chart Which is exactly right. Had it still been the earlier warn-and-continue version, it would have quietly published an edge-only chart and committed it over the good three-series one, with nothing in the log saying so. Fix: default to charting this repo alone, which works with the built-in token. The repo list is now read from STAR_HISTORY_REPOS, so the sibling repos can be added later by supplying a PAT with read access to them — opt-in, rather than a default that 403s. Committed SVG regenerated to match, so local output and CI output are identical; otherwise the two would disagree and the workflow would commit every week, which is the churn the no-change guard exists to stop. Captions in the README and on the landing page updated to say the chart covers this repo, and how to widen it.
|
Warning Review limit reached
Next review available in: 25 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
PR Reviewer Guide 🔍Here are some key observations to aid the review process:
|
PR Code Suggestions ✨No code suggestions found for the PR. |
User description
Follow-up to #155. I test-ran the new workflow after merging and it failed on its first live run — and the fail-closed behaviour CodeRabbit asked for in #155 is precisely why we found out cleanly instead of silently shipping a worse chart.
What happened
A workflow's built-in
GITHUB_TOKENis scoped to its own repository. ReadingOpenStrap/protocolfrom a job running inOpenStrap/edgereturns 403:Which is exactly the right outcome. Under the original warn-and-continue version, this would have quietly generated an edge-only chart, committed it over the good three-series one, and logged nothing that looked like a problem. CodeRabbit's finding earned its keep within the hour.
Fix
Default to charting this repo alone, which works with the built-in token. The repo list now comes from
STAR_HISTORY_REPOS, so siblings can be added later by supplying a PAT with read access — opt-in, rather than a default that 403s:STAR_HISTORY_REPOS="OpenStrap/edge,OpenStrap/protocol" python3 tool/gen_star_history.pyVerified both paths: default →
edge · 334; override →edge · 334+protocol · 11.Why the committed SVG changed too
It has to. If local output and CI output disagree on the repo set, the SVG flip-flops between one and three series and the workflow commits a revision every week — the exact churn the no-change guard exists to stop. Regenerated so the two are byte-identical. Re-confirmed determinism across consecutive runs.
Honestly the single-series chart also reads better:
protocol(11) andanalytics(5) were near-flat lines againstedge's 334, so they added noise more than information.Captions in the README and on the landing page updated to say what the chart covers and how to widen it.
Docs + one script. No Dart touched.
PR Type
Bug fix
Description
Fix CI failure: default to charting only
OpenStrap/edge(built-in token scope)Make repo list configurable via
STAR_HISTORY_REPOSenv var for opt-in PAT useUpdate README and landing page captions to reflect single-repo chart
Regenerate committed SVG so local and CI output are byte-identical
Diagram Walkthrough
File Walkthrough
gen_star_history.py
Make repo list env-configurable, default to edge onlytool/gen_star_history.py
(
OpenStrap/edge)STAR_HISTORY_REPOSenvironmentvariable
(token scope, flip-flop risk)
README.md
Update README captions for single-repo star chartREADME.md
alttext on star-history image to reflect single-repo chartSTAR_HISTORY_REPOSopt-in for cross-repo PAT usageindex.html
Update landing page image alt text for single-repo chartdocs/index.html
altattribute on star-history image to sayOpenStrap/edgeonly